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Abstract — Distributed collaborative software development 
tends to make artifacts and decisions inconsistent and uncertain. 
We try to solve this problem by providing an information 
repository to reflect the state of works precisely, by managing 
the states of artifacts/products made through collaborative work, 
and the states of decisions made through communications. In 
this paper, we propose models and a tool to construct the 
artifact-related part of the information repository, and explain 
the way to use the repository to resolve inconsistencies caused 
by concurrent changes of artifacts. We first show the model and 
the tool to generate the dependency relationships among UML 
model elements as content of the information repository. Next, 
we present the model and the method to generate change support 
workflows from the information repository. These workflows give 
us the way to efficiently modify the change-related artifacts for 
each change request. Finally, we define inconsistency patterns 
that enable us to be aware of the possibility of inconsistency 
occurrences. By combining this mechanism with version control 
systems, we can make changes safely. Our models and tool are 
useful in the maintenance phase to perform changes safely and 
efficiently. 



I. Introduction 

Collaboration is unavoidable in software development be- 
cause of the increased scale and complexity of projects. 
However, collaboration is not an easy task, and bad collab- 
oration contributes to project failure. One common problem 
in a collaborative work is different understandings of the 
state of shared artifacts, interface definitions, and agreements 
made through communications. These recognition gaps are 
more serious in a distributed environment, where geographical 
distribution of workers can cause convergence delay. J. D. 
Herbsleb reported that "distributed work items appear to 
take about two and one-haft times as long to complete as 
similar items where all the work is collocated" |7|. Therefore, 
in addition to ordinary software development environments 
(SDEs), additional support for distributed collaborative work 
is necessary. In d, (5), we have presented an approach to 
deal with the instability of the state of distributed collaborative 
work, which tends to make artifacts and decisions inconsistent 
and uncertain. This approach proposed technologies for shar- 
ing the instability of the state of the distributed collaborative 
work, and for incremental reinforcement of consistencies and 
certainties (Fig. [T]). 

Regarding the uncertainty problem, we have proposed a 
method for decision management support. In a distributed 



collaborative environment, email is one of the most popular 
means of communication among workers. However, in email 
communications, a discussion topic may involve many emails, 
and one email may contain many topics. Therefore, it is helpful 
for the participants in deliberations to grasp the progress and 
the reasoning of the deliberation for each subject. In (3), we 
have presented a model and a tool for extracting deliberation 
threads from email communications. This tool helps to reduce 
the gap in understanding collaborative work among workers, 
and leads them to reach a decision. 

Regarding the inconsistency problem, this paper presents 
a Change Support Model (CSM) for distributed collaborative 
work, in which we propose models and a tool to construct 
the artifact-related part of the information repository, and we 
explain the way to use the repository to resolve inconsistencies 
caused by concurrent changes of artifacts. CSM is a combina- 
tion of model-based approach, process support approach, and 
awareness support approach, the main collaboration techniques 
in software engineering [2]. CSM is useful in the maintenance 
phase to perform changes safely and efficiently. 

The information repository contains UML model elements 
with dependency relationships. We will show a model and 
a tool to generate the dependency relationships among the 
UML model elements. Next, we present a method to generate 
a Change Support Workflow (CSW) for each change request 
from the information repository. The CSW gives us a way to 
modify the related artifacts for each change request efficiently. 
Change workers will perform change activities for each change 
request by following the generated CSW. 
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Fig. 1. An approach to acting in the presence of inconsistencies and 
uncertainties in a distributed collaborative environment 
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Fig. 3. Relationships among software artifacts 



Fig. 2. Inconsistency in a change environment 

Concerning the inconsistency detection, previous studies 
have concentrated on detecting code conflicts by using syn- 
chronization function of version control system, or by mon- 
itoring the behaviors of developers in different workspaces. 
However, in these works, conflicts are detected after changes 
have been finished or are being executed, and the awareness of 
developers is limited to the program elements being accessed 
concurrently by others. In CSM, we identify patterns of 
inconsistency existing among concurrently executing CSWs 
to detect the possibility of inconsistency occurrences earlier. 
In addition, by using CSWs, CSM can provide change workers 
with very comprehensive views of shared artifacts. 

The rest of this paper is organized as follows. Section 2 
provides an overview of our approach to building the CSM and 
introduces its framework. We present our method and the tool 
to generate the dependency relationships among UML model 
elements in Section 3, and develop the method for generating 
CSWs from these dependency relationships among artifacts 
in Section 4. Section 5 handles awareness support regarding 
inconsistencies. Section 6 reports related work, and finally, 
Section 7 concludes the paper and discusses future work. 

II. Approach 

A. Overview 

Distributed collaborative software development tends to 
make artifacts and decisions inconsistent and uncertain. Our 
general approach to this problem is to construct an informa- 
tion repository that can reflect the state of work precisely, 
by managing the states of artifacts/products made through 
collaborative work and the states of decisions made through 
communications, and to develop functions that can detect 
inconsistencies and uncertainties (Fig. [T]). In this paper, we 
apply this approach to the change environment to deal with 
the inconsistency problem that occurs when several changes 
of artifacts are made concurrently. 

Changes are inevitable during software development and af- 
ter delivery. In a distributed collaborative environment, change 
implementation is difficult because software artifacts with very 
complex relationships are created based on the collaboration of 
many workers. Also, lack of awareness of concurrent work of 
workers contributes to (potential) inconsistencies on artifacts 
(See Fig. 0. Supporting change workers to work safely and 
efficiently is the objective of the CSM. 

When a change worker makes a change on an artifact, 
called change root, the artifacts connected to this artifact by 



dependency relationships may be affected. Dependency is a 
relationship between two artifacts in which a change to one 
artifact may affect the other. By repeating the process, we can 
see that a change initiated from a change root can spread to 
many artifacts, which in turn can reach the change root by 
dependency relationships. In the example shown in Fig. [2 
from a change request (CR) on artifact 1 (CRi), Worker 1 
(Wi) may have to implement changes on artifacts 3, 4, 6, 
and 7. Similarly, from CR 2 on artifact 2, Worker 2 {W 2 ) 
may have to implement changes on artifacts 2, 4, 5, 7, and 
8. Because the two workers work independently, they may 
not have sufficient information about each other's activities. 
Therefore, if these change requests are implemented concur- 
rently, inconsistency may happen on shared artifacts 7 and 
8. To implement changes efficiently, we will formalize change 
implementations on related artifacts for each change request in 
the system by a special workflow, Change Support Workflow 
(CSW). A CSW is a sequence of activities defined to carry out 
a change request. Activities in a CSW take care of creating 
new artifacts or modifying exiting ones. To implement changes 
safely, a mechanism to handle inconsistency is indispensable 
in CSM. 

1) Dependency Generation: To generate a CSW for a 
change request, we need to identify the impacted artifacts 
based on dependency relationships among artifacts. 

We classify relationships among software artifacts into two 
groups (Fig. [3]). The first is intra- relationships that are relation- 
ships among model elements in the same diagram. The second 
is inter-relationships that connect related model elements in 
different diagrams or in different phases together. Based on 
these classifications, we name dependency relationships in the 
inter-relationship group ' 'inter- dependency'' and dependency 
relationships in intra-relationship group u intra- dependency". 
Examples of intra-dependency relationships are generaliza- 
tion, association (aggregation, composition), and usage depen- 
dency (call, instantiation, send, parameter). Examples of inter- 
dependency relationships are trace, refinement and derivation. 
In this paper, we will pay attention to automatic generation of 
inter-dependencies among UML model elements, named Basic 
Dependency Relationships (BDRs). 

• Define BDR types by analyzing dependency relationships 
defined in UML 1.5. 

• Develop a BDR Generation Engine to generate BDRs 
among UML model elements. This engine operates based 
on a set of rules for identifying BDRs among UML 
model elements. It receives UML model elements in 
UML diagrams and process information (phase names 
and phase orders), and returns the UML model elements 
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Fig. 4. Conceptual framework of CSM 



with BDRs attached. 

2) CSW construction: Based on dependency relationships 
among software artifacts and change requests. By tracing 
dependency relationships, we can identify data elements (soft- 
ware artifact impacted by a change request) and the control 
flow (change order of impacted software artifacts) of a CSW. 

3) Inconsistency Awareness: Consider the following points: 

• Establish agreements on using CSWs among workers. 
Every worker will work based on a CSW. 

• Inform workers about (potential) inconsistencies, and 
support them in inconsistency resolution by collecting 
and analyzing information of CSWs in the system. 

B. CSM Framework 

Fig. H] describes the conceptual framework of the system 
with the following main components: 

• Dependency Repository: is a part of Information Repos- 
itory. This repository contains UML model elements 
linked by dependency relationships. 

• CSW Repository: is a part of Information Reposi- 
tory. It contains information of CSWs executed in local 
workspaces of workers. 

• Version Control System: manages changes to software 
artifacts. 

• Dependency Generator: generates dependency relation- 
ships among software artifacts in Version Control System 
and stores them in Dependency Repository. 

• CSW Generator: generates CSWs based on change 
requests and information in Dependency Repository, and 
stores them in CSW Repository. 

• Inconsistency Awareness: notifies workers of the pos- 
sibility of inconsistency based on collected information 
of CSWs at clients, and information in Dependency 
Repository and CSW Repository. 

The main processing flow of the system is as follows: 

1) Generate dependency relationships by using Depen- 
dency Generator component (1.1, 1.2). 

2) Generate a CSW for each change request from workers 
by using CSW Generator component (2.1, 2.2, 2.3). 

3) Notify the workers of the possibility of inconsistency in 
the newly generated CSWs and executing CSWs in the 
system using Inconsistency Awareness component (3.1a 
or 3.1b, 3.2a and 3.2b, 3.3). 



III. Dependency Generation 

In this section, we will define types of BDRs by analyzing 
dependency relationships of UML, and present a method and 
a tool for automatic generation of BDRs from UML diagrams 
created during the software development process l23l . 

A. Basic Dependency Relationship 

UML 1.5 has defined 'dependency' as a relationship be- 
tween two elements in which a change to one element, 
the Target, may affect or supply information needed by the 
other element, the Source. Dependency has many varieties 
that represent different kinds of relationships: Abstraction, 
Binding, Permission, and Usage. In addition to these varieties, 
we realize that developers also create some implicit relation- 
ships among UML model elements: Copy, relationship among 
copies of an element but in different diagrams, and Inclusion, 
the whole-part relationship between an element and its internal 
members or between a diagram and its elements. By analyzing 
the 'dependency' of UML 1.5 and the dependencies generated 
implicitly by developers, we propose a set of new generable 
Basic Dependency Relationships (BDRs) between UML model 
elements: Exist Together, Information Sharing, Copy, and 
Concept (see Table U). 

1) Exist Together: The Source does not exist without the 
Target. Exist Together is defined from Usage and Inclusion 
relationships. Usage and Inclusion relationships can be gen- 
erated automatically by comparing the names of UML model 
elements or analyzing the whole-part relationship. Therefore, 
we can generate Exist Together relationships automatically if 
the names of model elements are comparable or the Inclusion 
relationship can be analyzed. 

2 ) Information Sharing: Information of the Target is a part 
of information of the Source. Information Sharing has been 
extracted from Binding, Permission, and Usage. Although 
Binding and Permission cannot be generated automatically, 
Usage can be generated automatically if the names of UML 
model elements are comparable. Therefore, when at least one 
name in the shared information group is comparable, we can 
generate Information Sharing relationship automatically. 

3) Copy: Information of the Target and the Source is the 
same. This relationship is extracted from the Copy relationship 
generated implicitly by developers. Copy relationship can be 
generated automatically among UML diagram elements which 
are in the same phase, and have the same name and type. 

4 ) Concept: The Source and the Target represent the same 
concept but the Source is more concrete. Concept has been 
extracted from Abstraction. Abstraction can be generated au- 
tomatically by comparing the names of UML model elements 
and using the process information. Therefore, we can generate 
Concept relationship automatically if process information is 
given and elements representing the same concept are named 
similarly. 

B. Dependency Generation Model 

To generate the dependency relationships automatically, we 
define a Dependency Generation Model (DGM) consisting of 
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Fig. 5. Method for generating BDRs automatically 



comparison rules, addition rules, and selection rules. Compar- 
ison rules look for pairs of UML model elements that may 
have some BDRs, based on the similarity in names between 
UML model elements, and inclusion relationships between 
a diagram and its components. Addition rules identify BDR 
candidates that may be set to a pair of UML model elements. 
Regarding the information about phase, diagram, type and 
name of UML model elements, selection rules will choose 
one BDR from the BDR candidates found by addition rules to 
attach to the selected pair. Based on DGM, BDR Generation 
Engine accepts as input a group of UML diagrams and their 
process information (phase names and phase orders). Outputs 
will be these UML diagrams with newly added BDRs (see 
Fig. El). 

1) Comparison rules: Find pairs of UML elements to 
which BDRs may be attached. A BDR may exist between 
two UML model elements if they satisfy one of the following 
conditions: 

• Contained: The name of the Target is included in the 
name of the Source, for example "Elevator" and "Eleva- 
torControl". 

• Similar: The name of the Target is similar to the name 
of the Source, for example "FloorLampInterface" and 
"FloorLampInterf aces" . 

• TypeSim: The type of the Target is similar to the name 
of the Source, for example ": FloorLampInterf aces" and 
' 'FloorLampInterface' ' . 

• SimType: The name of the Target is similar to the type 
of the Source, for example "FloorLampInterface" and ": 
FloorLampInterf aces" . 

Table HI] shows suitable comparison conditions for each type 
of Target and Source. 

2 ) Addition rules: Identify BDRs which can exist between 
two UML model elements satisfying the comparison rules. 
We classify UML model elements into new categories which 
we call Generation Model Elements (See Table [HI]). We also 
define types of BDR which can be set between two Generation 
Model Elements (See Fig. [6]). Based on these instructions, 
we can find BDR candidates between any two UML model 
elements by mapping them to Generation Model Elements. 
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TABLE III 
GENERATION MODEL ELEMENTS 
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3) Selection rules: Decide on the BDR candidates obtained 
after applying the addition rules to two UML model elements 
satisfying the comparison rules. In Table [IVJ we describe how 
to choose BDR by using information of names, types, diagram 
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4. BDR Selection based on Selection rules 



and phases of UML elements. 

• Information Sharing: Two UML elements are in the 
same phase but in different diagrams, and are of different 
types. 

• Copy: Two UML elements are in the same phase but in 
different diagrams. They have the same name and are the 
same type. 

• Concept: Two UML elements are in adjoining phases. 

• Exist Together: Two UML elements are in the same 
diagram, and certainly in the same phase. 
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Fig. 9. Main window of the Impact Analysis Tool 



Information Sharing and Concept. Because both artifacts are 
in the same phase, we decide on Information Sharing for 
the BDR between these artifacts. Finally, information about 
a BDR, Information Sharing, with the class "ElevatorControl" 
at the Target and the object ": ElevatorControl" at the Source 
is added to the system. 



C. Automatic BDR Generation 

BDR generation includes five steps: 

1) Extraction of potential UML elements: Search pairs 
of UML model elements satisfying conditions of the 
comparison rules. 

2) Retrieval of Generation Model Elements: Find Gen- 
eration Model Elements corresponding to these UML 
elements. 

3) BDR Candidate Identification: List all BDR candi- 
dates between pairs of UML elements based on addition 
rules. 

4) BDR Selection: Choose a suitable BDR for each pair 
of UML elements based on selection rules. 

5) BDR Addition: Add the selected BDRs to the corre- 
sponding pairs. 

Fig. [7] shows an example of automatic BDRs generation. 
Assume that we have some UML artifacts including the class 
"ElevatorControl" and the object ": ElevatorControl" which are 
in the same phase. Based on the comparison rules, these two 
UML elements satisfy the SimType condition. Therefore, we 
perform the second step, mapping these artifacts to Generation 
Model Elements. Using Table [nil Generation Model Elements 
of the class "ElevatorControl" and the object ": ElevatorCon- 
trol" are Classifier element and Instance element, respectively. 
Next, the addition rules are applied. The diagram in Fig. 
shows that there are two candidates for the BDR between 
the class "ElevatorControl" and the object ": ElevatorControl": 



D. Impact Analysis Tool 

We have developed an impact analysis tool that implements 
dependency generator component and performs impact analy- 
sis process starting from a change root. This tool is developed 
as a plugin of Eclipse with three-layer framework (See Fig. [8]). 
We have performed two case studies to evaluate our method. 
The precision of the generated BDRs is from 92.3% to 93.3%, 
and the recall is from 83.7% to 87.7% l23l 

Fig. [9] shows a screen shot of the tool when we find impact 
elements of a change request by choosing the change root. 
Different colors mean different dependency chains. 

IV. Change Support Workflow Generation 

In this section, we will present the way to generate CSWs 
based on dependency relationships among artifacts. 

A. CSW Definition 

As a workflow, a CSW must contain basic information such 
as change activities, software artifacts accessed by change 
activities, and change orders. In addition, to support inconsis- 
tency detection, we need to store active intervals of activities 
in a CSW. Regarding access control, information of the change 
worker associated with an activity will be recorded. Below is 
a formal definition of CSW. 

Definition 1: A Change Support Workflow is a tuple w = 
< id, A, F, D, T, W, GD, GW > where: 
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id is the workflow identifier. 
A is a set of activities. 

F C (Ax A) is a. set of arcs (flow relation) that represent 
the orders of change activities. 

D is a set of software artifacts accessed by activities of 
CSW. 

T = {r, w} is a set of tasks on software artifacts (r: 
read, w: write), read means that this artifact is used to 
implement a change on another artifact, write means that 
this artifact will be changed. 

W is a set of workers who execute activities of CSW. 

GD : A x T 2 D is a function that returns a set of 

artifacts associated with an activity and a task. 

GW : A 2 D is a function that returns the workers 

associated with an activity of CSW. 

GT \ A^r ((R+ Uoo) x U oo)) is a time interval 

function that returns the start time and the finish time of 

an activity. R + is the set of all positive real numbers, oo 

denotes an undecided start time or finish time. 
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B. CSW Generation 

When a worker makes a change to an artifact, change root, 
this change may affect artifacts that have BDRs with the 
change root, and require extra modifications. By following 
BDRs among artifacts, we can find all potentially impacted 
elements. 

Here is a general algorithm for identifying dependency 
graph starting from a root artifact. Dependency graph is 
a directed graph where vertexes are potentially impacted 
artifacts, and edges are BDRs among the potentially impacted 
artifacts. An edge e = (x\y) is considered to be directed from 
node x to node y if there is a BDR with the Target y and the 
Source x. 

1) The initial set of vertexes is the root artifact itself. 

2) For each artifact in the vertex set, if there is a BDR 
having this artifact as the Target, add the Source element 
to the set if it is not already in the set, and add an edge 
directed from the Source to the Target. 

3) Repeat Step 2 until all vertexes are examined and no 
new artifact appears. 

The most straightforward way to generate a CSW from 
a dependency graph is to use the same structure as in the 
dependency graph. Each artifact is mapped to a new activity, 
and each BDR between two artifacts becomes an arc con- 
necting two corresponding activities. However this method is 
just suitable for a very sparse dependency graph whereas a 
dependency graph is a dense graph in reality (See an example 
of a dependency graph at the bottom left corner of Fig. [TUb . 
Therefore, the structure of a CSW generated by this method 
is not a good formulation for change support, because several 
artifacts should be examined together. So we use a grouping 
technique to identify groups of strongly related artifacts and 
map each group to an activity in a CSW. A group contains 
artifacts connected together by Copy or Information Sharing 
relationships. 

• Put artifacts connected by Copy or Information Sharing 
relationships into a group. 



Fig. 10. Example of generating CSWs 

• Find the group containing the root artifact. Assign the 
root artifact to the write data set of the first activity in 
the CSW, and the remaining artifacts to the write data set 
of the second activity of the CSW. 

• For the remaining groups, create the same number of 
new activities so that each new activity will receive each 
corresponding group as its write data set. 

• If there is at least one Concept relationship between two 
artifacts in two different activities, create an arc from the 
activity containing the Target to the activity containing 
the Source. 

• If the write data set of an activity contains an artifact, i.e. 
a diagram, that is the Target element of at least one Exist 
Together, this activity will be classified as a composite 
activity. A composite activity can include many CSWs 
whose root artifacts are the Source elements of these Exist 
Together relationships. 

Based on Definition 1, the generated CSW will include 
information about elements A, F, D, T, and GD of a CSW. 
Elements related to workers, W and GW, are decided by 
designers or project managers. The time interval, GT, will be 
collected during workflow execution. 

Fig. [TO] describes an excerpt of a non-distributed Elevator 
Control System [22] with some important diagrams in the 
requirement definition phase (Dl), analysis phase (D2, D3, 
D4 and D5) and subsystem design phase (D7 and D8). We 
assume that there is a change request on Select Destination 
use case, Artifact 1.1. For simplicity, we just show important 
BDRs among artifacts. Applying the above algorithm with 
the change root as Artifact 1.1, we have CSW W with two 
activities in which Activity 2 will modify Artifact 1.2, diagram 
D3. We assume that this change may affect three artifacts 
inside this diagram, 1.2.1.1, 1.2.2.1, and 1.2.3.1. Therefore, 
from the composite activity 2, three CSWs are built with these 
root artifacts: 1.2.1.1, 1.2.2.1, and 1.2.3.1 respectively. These 
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three CSWs are also considered as three branches originating 
from the composite Activity 2. 

C CSW Execution Control 

A CSW can be in one of three states: planning, executing, 
and finished. A CSW is in the planning state when it is 
generated automatically by the CSW Generator component at 
build time (CSW Generation Section). When a change worker 
starts the planning workflow, this workflow will move to the 
executing state. When the change worker finishes the last 
activity of the executing workflow, the CSW will be in the 
finished state, a finished workflow. 

When a CSW moves from the planning state to the execut- 
ing state, some values of the workflow may be modified by 
workers, such as worker assignment. Also, the change orders 
of artifacts which are assigned to the same activity in the 
planning phase, are decided. Start time and finish time of each 
activity can also be identified. 

However, the most important thing that happens at run 
time is the spread of dynamic change. Artifacts in these 
CSWs are not isolated, but are connected with artifacts in the 
same diagram by intra-dependency relationships. Because of 
these relationships, when these CSWs are executed, changes 
on artifacts being modified by activities in these CSWs will 
spread to the intra-dependency related artifacts. In the example 
described in Fig. [lOl the artifacts which may be affected when 
CSWs W.2.1, W.2.2, and W.3.3 start executing are marked with 
thick red borders. Therefore, we need to dynamically generate 
new CSWs to meet the arising changes by using the same 
process described in the previous section. We call the original 
CSWs main CSWs, and the newly arising CSWs sub-CSWs. 

To manage CSWs of a change request easily, we classify 
these CSWs into different grades, starting from 1 st grade. 1 st 
Grade CSWs are the main CSWs. CSWs from 2 nd Grade and 
higher are sub-CSWs. 2 nd Grade CSWs are built based on 
1 st Grade CSWs. A 2 nd Grade CSW is a CSW of which the 
root artifact has intra-dependencies with artifacts in the 1 st 
Grade CSW, and has not yet appeared in any existing CSWs. 
After identifying the root artifact, we can find the elements of 
a new CSW by tracing BDRs starting from this root artifact. 
In general, n + 1 th Grade CSWs will be built based on n th 
Grade CSWs in the same way (Fig. fTTT) . 

To ensure that changes are executed in an exact and effective 
manner, we schedule CSWs of a change request in a pipeline 
mode. If two artifacts in two adjoining grade CSWs have an 
intra-dependency relationship, the activity in the higher grade 
CSW should be executed after the activity in the lower grade 



Fig. 12. Approach to handling inconsistencies 

CSW (See Fig. fTTb). CSM supports the change workers who 
execute CSWs of the same change request, by notifying them 
of common points, and forcing them to follow the execution 
order constraints, the intra-dependency relationships, between 
their own CSWs and others. 

V. Inconsistency Awareness 

Most previous works in inconsistency awareness concen- 
trated on code conflict, a kind of inconsistency caused by 
concurrent changes on shared artifacts. In (6), the authors 
classified conflicts into two types: direct conflict and indirect 
conflict. Direct conflicts are caused by concurrent changes to 
the same artifact. Indirect conflicts are caused by changes in 
one artifact affecting concurrent changes in another artifact. In 
general, indirect conflicts are more dangerous because they are 
detected late. CSM will consider both types of conflicts. We 
also pay attention to other types of inconsistencies occurring 
when activities in concurrent CSWs modify artifacts connected 
by some dependency relationships. 

Like most other systems, CSM uses Version Control Sys- 
tems (VCSs) to manage artifacts, and to support collaboration 
and parallel work. VCSs can detect direct conflicts by com- 
paring check-in versions. However, VCSs cannot help in the 
case of indirect conflicts, because changes are implemented on 
different artifacts. Even if in the case of direct conflicts, VCSs 
detect them at check-in time when all changes have finished. 
This is a waste of time and effort. These inconsistencies should 
be detected as soon as possible. Our method is to detect 
(potential) inconsistencies at both build time and runtime. 

Fig. [121 shows our approach to handling inconsistency using 
client- server architecture. Change workers use Change Support 
Clients to interact with their CSWs. A Change Support Server 
monitors CSWs at clients through Change Support Clients, 
analyzes collected information, and notifies change workers 
of (potential) inconsistencies. Change workers will need to 
negotiate to find resolutions for the inconsistencies. 

A. Inconsistency Detection 

Potential inconsistencies at build time are detected by 
checking the existence of shared artifacts among planning 
workflows, or among a planning workflow and executing 
workflows. Right after generating a new planning workflow, 
the system will check potential inconsistencies between the 
new workflow and other planning workflows or executing 
workflows. If there are shared artifacts between two planning 
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workflows, there is a chance for the related workers to 
cooperate to reconsider their change requests and CSWs. If 
shared artifacts are detected between the new workflow and an 
executing workflow, new workflow should be delayed until the 
executing workflow has finished. Another candidate method is 
to use negotiation, as in the previous case. 

To detect inconsistencies at runtime, we identify patterns of 
(potential) inconsistencies among executing workflows. These 
patterns are special cases of Unintentional Change in In-use 
Data (UCID) patterns that we have presented in (4), 0. We 
assume that a worker will check out the latest versions of all 
necessary artifacts at the beginning of an activity, and check in 
modified artifacts at the end of each activity for all activities 
in his CSW. 

The following notations are used in the definitions of 
inconsistency patterns: 

• COa(cI): Activity A checks out the latest version of 
artifact d. 

• T — COa(cI)'. Point in time when activity A checks out 
artifact d. 

• V — COa(cI)'. Version of d when it is checked out by 
activity A. 

• CIa(cI): Activity A checks in artifact d. 

• T — CIa(cI): Point in time when activity A checks in 
artifact d. 

• V — CI a (d) : Version of d when it is checked in by activity 
A. 

• [T - CO A , T - CI A ] : Active Interval of activity A. 

Pattern 1 : WW Direct Conflict occurs when two activi- 
ties in different CSWs concurrently modify (write) the same 
version of an artifact, and create two new conflicting versions. 



Fig. lT3li describes a WW Direct Conflict between two 
activities A and B in different CSWs: 

• A and B have overlapping Active Intervals: [T — 
CO A (d),T-CI A (d)} n[T-CO B (d),T-CI B (d)}^® 

• Versions of the shared artifact between A and B at check- 
out time are the same: V — COA(d) — V — CO B (d) 

• Versions of the shared artifact between A and B at check- 
in time are different: V - CI A (d) + V - CI B (d) 

Based on Fig. [T3k we can detect the possibility of a WW 
Direct Conflict at the start time of activity B, instead of at the 
finish time of B, when change worker checks in the shared 
artifact. 

Pattern 2 : Potential Indirect Conflict occurs when two 
activities in different CSWs concurrently modify two differ- 
ent artifacts that are connected by dependency relationships 
(BDRs or intra-dependency relationships). 

Fig. IT3b describes a Potential Indirect Conflict between two 
concurrent activities A and B in different CSWs: 

• A and B have overlapping Active Intervals: [T — 
CO A (d 2 ) 1 T-ClA(d2)}n[T-CO B (d 6 ),T-CI B (d 6 )} + 


• c?2 can be reached from de by dependency relationships 
Based on Fig.[T3b, we can detect this risk at the start time of 

activity B when change workers checks out the artifact d^ that 
depends on the artifact d 2 being modified by the concurrent 
activity A. 

We call this pattern potential indirect conflict because con- 
flict just happens between two artifacts if modification of an 
artifact is based on the content of the other artifact. This special 
situation is called RW Direct Conflict. 

RW Direct Conflict occurs when an activity A uses (read) 
a version of an artifact d to modify (write) another artifact, 
and an activity B in a different CSW concurrently modifies 
(writes) the same version of d with A. 

Fig. IT3b describes an RW Direct Conflict between two 
activities A and B in different CSWs. B will modify (write) 
d\ based on d. 

• A and B have overlapping Active Intervals: 

[T - CO A (d),T - CI A (d)} H [T — CO^d.d^.T - 
C/ B (di)] ^0 

• Versions of the shared artifact between A and B at check- 
out time are the same: V — COA(d) = V — CO B (d) 

• The version of the shared artifact at check-in time of 
A is different from the version at check-out time of B: 
V-CI A (d) ^V-CO B (d) 

Pattern 3: WWW Potential Indirect Inconsistency occurs 
between two artifacts that are connected to the same artifact 
by dependency relationships (BDRs or intra-dependency rela- 
tionships) and are modified (written) by two activities in the 
same CSW, because an activity in a different CSW (wrote) 
to this shared artifact sometimes during the interval between 
these two activities. 

Fig.[T3h describes a WWW Potential Indirect Inconsistency 
between three activities A, B, and P in which A and B are in 
the same CSW, and P is in a different CSW: 

• P happens sometimes during the interval between A and 
B: [T-CO P (d 2 ),T-CIp(d 2 )} c [T - CI A (<k), T - 
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CO B (d 7 )] 

• d,2 can be reached from d§ and dj by dependency 
relationships 

Based on Fig.[T3ll we can detect this potential inconsistency 
at the start time of activity B or activity P. 

We name this pattern potential indirect inconsistency be- 
cause inconsistency just happens between two artifacts in the 
same workflow if modifications of both artifacts are based on 
the content of the same artifact. This special situation is also 
called RWR Direct Inconsistency. 

RWR Direct Inconsistency occurs when two activities in 
the same CSW use (read) different versions of an artifact to 
modify (write) other artifacts, which are different from the 
initial plan of their CSW, because an activity in a different 
CSW (wrote) to this shared artifact sometimes during the 
interval between these two activities. 

Fig. IT3b describes a RWR Direct Inconsistency between 
three activities A, B and P in which A and B are in the same 
CSW, and P is in a different CSW. A and B will modify (write) 
d\ and d 2 , respectively based on d. 

• P happens sometimes during the interval between A and 

B: [T - CO P (d),T - CI P (d)\ C [T — CI A {di),T - 
CO B (d,d 2 )} 

• Version of the shared artifact at check-in time of A is the 
input of P: V — CI A (d) = V- CO P (d) 

• Version of the shared artifact at check-in time of P is the 
input of B: V — CI P (d) = V - CO B (d) 

Pattern 4: W 2 W Potential Indirect Inconsistency occurs 
when two activities in the same CSW modify (write) two 
artifacts, of which the artifact modified by the later activity is 
connected to the previous artifact by dependency relationships 
(BDRs or intra-dependency relationships), and another activity 
in a different CSW (wrote) to the previous artifact sometimes 
during the interval between these two activities. 

Fig. IT3V describes a W 2 W Potential Indirect Inconsistency 
between three activities A, B, and P in which A and B are in 
the same CSW, and P is in a different CSW: 

• P happens sometimes during the interval between A and 

B: [T-CO P (d 2 ),T-CIp{d 2 )} c [T - CI A (d 2 ), T - 
CO B (d 7 )} 

• d 2 can be reached from d 7 by dependency relationships 

Based on Fig. [I3f, we can detect this type of potential 
inconsistency at the start time of activity B or activity P. 

We name this pattern potential indirect inconsistency be- 
cause inconsistency just happens between two artifacts in the 
same workflow if modifications of both artifacts are based on 
the content of the same artifact. This special situation is also 
called WWR Direct Inconsistency. 

WWR Direct Inconsistency occurs when an activity of a 
CSW uses (reads) a different version of an artifact, instead 
of the version created by another activity in the same CSW, 
to modify (write) another artifact, because an activity in a 
different CSW (wrote) to this shared artifact sometimes during 
the interval between these two activities. 

Fig- Ej* describes a WWR Direct Inconsistency between 
three activities A, B, and P in which A and B are in the same 



CSW, and P is in a different CSW. B will modify (write) d x 
based on d. 

• P happens sometimes during the interval between A and 

B: [T - CO P (d),T - CI P (d)\ c [T - CI A (d),T - 
CO B (d,d 1 )] 

• Version of the shared artifact at check-in time of A is the 
input of P: V - CI A (d) = V - CO P (d) 

• Version of the shared artifact at check-in time of P is the 
input of B: V - CI P (d) = V - CO B (d) 

B. Inconsistency Resolution 

Resolving (potential) inconsistencies among CSWs is not 
simple because different workers design different CSWs for 
different change requests, and a designer may know nothing 
about the work of others. Therefore, the cooperation of change 
workers is the most important factor. When receiving a warn- 
ing of inconsistencies or potential inconsistencies from CSM, 
the related workers will contact with each other to conduct 
a negotiation. Face to face discussion, email, phone, instant 
messenger, etc. can be their communication means. Below are 
some methods for fixing inconsistencies which change workers 
can consider in their negotiation: 

• Use a fine-grain work approach. CSWs can still work con- 
currently if they modify different parts of inconsistency- 
related artifacts. 

• Create a new change request that is a combination of 
change requests implemented by inconsistency-related 
CSWs. We will replace these inconsistency-related CSWs 
with the new CSWs that implement the new change re- 
quest. This method can apply to potential inconsistencies 
between planning workflows. 

• Merge inconsistency-related parts of CSWs to create a 
new workflow. 

VI. Related Work 

In the change support field, much previous work focused on 
change impact analysis on source code [21 j. By generating and 
managing CSWs, our CSM aims to support not only impact 
analysis, but also change planning and change execution. 

Regarding collaborative inconsistency, most previous stud- 
ies are about code conflicts caused by concurrent changes 
of different developers. Traditional approach uses a version 
control system such as CVS fT3) or Subversion fT4ll in 
conjunction with the programming environment to address the 
problem of concurrent accesses. An issue with this approach 
is that conflicts are detected at check-in time after a user 
has finished his changes. To be able to catch conflicts while 
developers are implementing their tasks, workspace awareness 
techniques were proposed. Tools such as IBM's Jazz.net 
platform ifTOll or Microsoft's CollabVS system fTO augment 
the awareness of developers and propagate changes at file/class 
level immediately after they happen. Also, some researchers 
have investigated how to exploit the information produced 
by integrated development environments during development 
such as Mylyn lfT5l . Sypware fT6lL and Syde |[T2ll . Palantir 
[6] is the first awareness tool that tries to detect indirect 
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conflicts in addition to direct conflicts. A new approach to 
detect potential indirect conflicts was presented in CASI ifTTli . 

However, none of the previous works mentions conflicts 
among UML model elements. AMOR (13, SMoVer Q9), and 
COMOVER |20l are model versioning systems that consider 
conflicts among model elements. Nevertheless, like other 
VCSs, conflicts in these systems are just detected at check- 
in time. Also, conflict caused by concurrent changes is just 
one source of inconsistency. 

ADAMS 1 25] is an example of a different approach to 
support distributed collaborative work. It is a web-based 
system that integrates project management features and artifact 
management features. 

VII. Conclusion 

In this paper, we have presented a Change Support Model 
for distributed collaborative work. To help change workers im- 
plement change activity safety and efficiently, CSM generates 
Change Support Workflows based on dependency relationships 
among software artifacts. Towards CSW generation, we have 
proposed a model and a tool for automatic generation of Basic 
Dependency Relationships among UML model elements. In 
additon, CSM also considers inconsistency caused by con- 
current CSWs that work on shared artifacts or dependent 
artifacts. To detect inconsistencies as soon as possible, our 
method detects potential inconsistencies at both build time 
and runtime. We have also identified inconsistency patterns to 
help detect inconsistencies at runtime more effectively. CSM 
will help collect and analyze information of local CSWs to 
notify change worker about risky points. Some inconsistency 
resolutions have been proposed too. 

In future work, we will improve our method of inconsis- 
tency handling, especially inconsistency analysis and resolu- 
tion. Next, we will work on generating dependency relation- 
ships connecting UML model elements to source code. Finally, 
we will develop a tool that implements CSW generation and 
inconsistency awareness support. 
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